The fallback path.dirname(appDir) is incorrect when appDir is /project/src/app — it would produce /project/src/public instead of /project/public. In practice root is always passed from the call site in index.ts, so this won't be hit at runtime. But the fallback is misleading. Consider throwing or logging a warning if root is not provided, rather than silently computing a wrong path.

includes(".") is too broad here — it triggers tryServeStatic on any URL containing a dot (e.g. /api/v2.0/data). Both index.ts and the generated RSC entry use path.extname() for this check. This should be consistent:

Same includes(".") issue as above:

This static file check runs at the very end, after fallback rewrites have already been tried and failed. In contrast, prod-server.ts checks right after afterFiles rewrites resolve a .html path (line 901) and again after fallback rewrites (line 923). The dev server should match the prod behavior:

1. Check for static file right after afterFiles rewrites resolve (before matchRoute)
2. Check again after fallback rewrites resolve

This avoids unnecessary fallback rewrite attempts and keeps dev/prod parity — something AGENTS.md explicitly calls out as important.

The fallback root ?? path.resolve(appDir, "..") is documented as wrong for src/app layouts, but still present. Since root is always passed from index.ts, this code path won't execute in normal usage. But if someone adds a new call site without root, they'll get a silently wrong path. Consider making this defensive:

Or more simply, just assert that root is provided and throw if not.

Minor: this traversal guard uses hardcoded "/" as the separator. On Windows (if anyone runs the dev server there), path.resolve returns backslash-separated paths, so startsWith(__publicRoot + "/") would fail. Consider using __nodePath.sep instead:

if (__publicFilePath.startsWith(__publicRoot + __nodePath.sep)) {

The index.ts version correctly uses path.sep. The generated RSC entry should match.

Dev/prod parity issue: This static file check only runs inside if (!match) — i.e. after afterFiles rewrites, matchRoute(), and fallback rewrites have all been attempted. In contrast, prod-server.ts (line 958) and index.ts (line 2984) check for static files immediately after afterFiles rewrites resolve, before route matching.

The current flow in the App Router dev path:

1. afterFiles rewrites /foo → /foo.html (line 1773)
2. matchRoute("/foo.html", routes) — always misses (line 1777)
3. Fallback rewrites attempted — unnecessary for .html (line 1780)
4. !match block finally checks public/ (here)

The check should be inserted right after cleanPathname = __afterRewritten; (after line 1773), and again after cleanPathname = __fallbackRewritten; (after line 1788), matching the other server paths. This avoids unnecessary matchRoute and fallback rewrite calls and keeps dev/prod parity — something AGENTS.md explicitly calls out.

When root is not provided, publicDir becomes null and static file serving silently degrades. Since the only call site (index.ts line 2347) always passes root, this won't fire in practice. But the silent null makes it easy for a future caller to miss root and get no error.

Consider either making root required (since the single call site always provides it), or logging a warning when it's missing.

Minor: ${JSON.stringify(MIME_TYPES)} creates a new object literal on every request that enters this branch. Since this is generated code inside _handleRequest(), the __mimeTypes constant should be hoisted to module scope in the generated code (near the other generated constants like routes, __configRewrites, etc.).

Nit: path.resolve(root, "public") is called twice — once for resolvedPublicDir and again inside the path.resolve(root, "public", ...) on the next line. You can reuse resolvedPublicDir:

Same pattern applies to the fallback block at lines 3030-3032.

Good — using path.extname() here is correct and consistent with the other server paths. The prior review flagged includes(".") as too broad; glad to see this was addressed.

Dev/prod parity issue — This is the third review cycle flagging this, and it remains the most important structural issue in the PR.

This static file check only runs inside if (!match), i.e. after afterFiles rewrites → matchRoute() → fallback rewrites have all been attempted. But in index.ts (line 2984) and prod-server.ts (line 958), the check runs immediately after afterFiles rewrites resolve, before route matching.

Concrete flow difference in the App Router dev path:

1. afterFiles rewrites /foo → /foo.html (line 1811)
2. matchRoute("/foo.html", routes) is called (line 1821) — always misses
3. Fallback rewrites attempted (line 1824) — unnecessary for a .html path
4. !match block finally checks public/ (here, line 1837)

The fix is to insert a static file check right after cleanPathname = __afterRewritten; (after line 1817) and again after cleanPathname = __fallbackRewritten; (after line 1832), matching the other two server paths. This avoids unnecessary matchRoute and fallback rewrite calls.

Per AGENTS.md: "When fixing a bug in any of these files, check whether the same bug exists in the others. Do not leave known bugs as 'follow-ups' — fix them in the same PR." The parity requirement applies equally to behavioral consistency across the three server implementations.

This ${JSON.stringify(MIME_TYPES)} expression creates a new object literal on every request that enters this code path. Since this is generated code inside _handleRequest(), the constant should be hoisted to module scope in the generated code (near the other generated constants like routes, __configRewrites, etc.).

Something like:

// At module scope in the generated code
const __mimeTypes = { ... };

Then reference __mimeTypes here instead of creating a new object each time.

When root is not provided, publicDir becomes null and static file serving silently degrades (the generated code has if (__extname && null !== null) which is always false). The only call site (index.ts line 2347) always passes root, so this won't fire in practice. But the silent degradation makes it easy for a future caller to miss root and get no error or warning.

Consider either:

• Making root required (since the single call site always provides it), or
• Logging a warning when it's missing, e.g.:

if (!root) console.warn("[vinext] generateRscEntry: root not provided, static file serving after rewrites will be disabled");

path.resolve(root, "public") is computed for resolvedPublicDir on the line above, then path.resolve(root, "public", ...) is called again here instead of reusing resolvedPublicDir. Minor but easy to clean up:

Same pattern applies to the fallback block at line 3031.

Same redundant path.resolve(root, "public") — reuse resolvedPublicDir here too:

Nit: resolvedPublicDir is computed on line 2985, but then path.resolve(resolvedPublicDir, "." + afterFilesPathname) re-derives the same base. This is fine, but the "." + afterFilesPathname pattern relies on afterFilesPathname starting with / (which it does, since it comes from afterRewrite.split("?")[0] which is a rewrite destination). Worth a brief comment or assertion to document this assumption, since if a rewrite destination ever lacked a leading slash, the path resolution would be wrong.

Same applies to the fallback block at line 3031.

Minor: path.resolve(root, "public") is computed again here identically to the afterFiles block above (line 2985). Since both blocks are in the same function scope, you could hoist resolvedPublicDir above both blocks to avoid redundant computation on every request that hits fallback rewrites.

(with resolvedPublicDir hoisted before the afterFiles block)

Good handling — the warning when root is missing is a clear improvement over the previous silent wrong fallback. The null propagation through the generated code (${JSON.stringify(null)} !== null → always false) cleanly disables the feature.

One thought: since root is effectively required for this feature to work and there's only one call site that always provides it, you could consider making it required (drop the ?) and let TypeScript enforce it. But the current approach is also fine for forward compatibility.

Subtle issue: ${JSON.stringify(publicDir)} is evaluated at code-generation time and embedded as a string literal in the generated module. This means the value is the publicDir at the time generateRscEntry() was called. If someone moves or symlinks the public/ directory after the dev server starts, the embedded path would be stale. This is fine in practice (dev servers restart on config changes), but it's worth noting.

More importantly: the __nodePath.resolve(__afterPublicRoot, "." + cleanPathname) call assumes cleanPathname starts with /. Since it comes from __afterRewritten (a rewrite destination), this should always be true for well-formed Next.js config. But a malformed rewrite destination like foo.html (no leading slash) would resolve relative to the current working directory rather than public/, potentially reading files outside the project. The traversal guard on line 1828 would catch this (the resolved path wouldn't start with __afterPublicRoot), so it's not a security issue, but worth a brief comment.

The bare catch {} silently swallows all errors, including permission errors (EACCES), too-many-open-files (EMFILE), etc. For a dev server, it would be helpful to log unexpected errors:

Same applies to the fallback block's catch at line 1871.

Good — using path.extname() here is correct and consistent with the other server paths. Clean improvement over the old includes(".") approach.

Nice consolidation. One missing entry that's fairly common in Next.js apps: wasm: "application/wasm". Cloudflare Workers apps in particular use .wasm files. Not blocking, but worth adding if you're touching this file anyway.

The publicDir is null when root isn't provided, and the generated code bakes in ${JSON.stringify(null)} !== null which is always false — effectively disabling the feature silently. The warning on lines 70-71 is good, but since the only call site (index.ts:2384) always passes root, consider making root required (drop the ?) so TypeScript enforces this at the call site. If a future caller forgets root, they'd get a type error instead of silently broken static file serving.

Non-blocking — the current code is safe.

Good — __mimeTypes is correctly hoisted to module scope in the generated code. This was flagged in earlier reviews and has been properly addressed.

The static file check is correctly positioned — it runs immediately after cleanPathname = __afterRewritten (line 1917) and before matchRoute (which comes after this block). This matches the positioning in index.ts and prod-server.ts. The automated reviewer's persistent complaint about this being inside if (!match) was incorrect for the current code.

One observation: __afterPublicRoot on line 1922 re-evaluates ${JSON.stringify(publicDir)} which is a static string literal, so the JS engine will inline it. But it could be even cleaner to reference a single module-scope constant (like __mimeTypes) rather than embedding the same JSON.stringify(publicDir) literal in both the afterFiles and fallback blocks. Minor style nit.

Good test coverage for both top-level and nested rewrites. One gap worth noting: there are no tests for fallback rewrites targeting static files. The code adds static file checking after both afterFiles and fallback rewrites, but only afterFiles is tested (the rewrite rules in the fixture config are all in afterFiles). Consider adding a fallback rewrite rule that maps to a .html file and a corresponding test — this would exercise the fallback static file path in all three servers.

Non-blocking since afterFiles is the common case from the original issue.